Re: /etc/utmp
Marc W. Mengel (mengel@dcdmwm.fnal.gov)
Tue, 29 Mar 94 09:54:38 -0600
In <9403282059.AA25931@rwing.UUCP> you write:
As for just locking down utmp, as you say, an empty group, such as utmp
would be a great idea. Except for one minor problem: See, MOST things
that need to write to utmp also have to open a port or pty, and the
ownership of that assigned port or pty is undefined - it could be root,
or some other user. It either has to be world writeable AND readable,
or chowned to the ID of the current user so that user can use more sane
permissions to function. I'm not sure I would really want to be forced
to have world-read/write access perms on a port cuz I cannot set it to
mode 600 or 660 because I am not the OWNER of that port.
They just exec a program who actually updates utmp. i.e. a program
owned by user fred, setgid to utmp, executable only by the user,
lets (only)fred update utmp.
That's great on SysV, where a user can change ownership, but not on BSD
derived systems where one cannot, not even to 'give a file away'. And
it still doesn't solve the problem where the unused pty one gets assigned
is owned by root or foo, and it needs to be owned by you (assuming you
aren't root or foo), or force you to live with world-write perms. Setting
it to exclusive open has other problems (like /dev/tty doesn't work).
As far as pty's, check out the pty daemon from Purdue, which you
connect to to request a pty be allocated to you, and when you die,
the daemon takes it back. Has a nice little library call to call
the daemon and get the pty. Clearly, since it involves either
creating pty nodes or changing their ownership it needs to be running
as root, and examined stringently for bugs, security problems, etc.
Kevin Braunsdorf <ksb@cc.purdue.edu> did it.